\newcommand{\srsl}[1]
{
\begin{center}
\small
\textit{#1}
\end{center}
}

\newcommand{\srdl}[2]
{
\begin{center}
\small
\textit{#1}\\
\textit{#2}
\end{center}
}
\section{Approach Description} \label{sec:approach}
\label{sec:approach}
To ensure that the PEPs enforcing access control in the code are well
 documented, we consider a two-folded approach. Our approach is depicted in Figure \ref{Approach Description} and is described as follows: First, we consider the use of static 
analysis of the application code. Our static analysis examines relationships between the classes of the application and determines the set of accesses that can be made from within the application code. 
The identification of this set of accesses enables us to identify accesses which may be regulated by the access control policy. It may also be used to help detecting misspecified security rules or errors 
in the implementation model of the application.
%So, if they are meaningful from the point of view of the security officer, there is no execution which may lead to a request to this particular rule. In the following, we exemplify these implicit enforcements of access control rules. As a result of this first analysis step, by intersecting the set of possible accesses and the specified ones, we obtain the list of rules which are enforced by PEPs. 
In the second step, we consider possible accesses in the application and we use dynamic analysis to map these possible accesses to their corresponding PEPs in the application code. More precisely, we first specify
 a permission rule to regulate a possible access and use the security policy mutation tool (MutaX) \cite{mutax} to negate this given rule 
(a prohibition is changed to a permission and vice versa). We then generate an execution trace for both the original and the mutated rule. When the policy is correctly enforced, the generated traces should differ at
exactly the point where the PEP is located. Consequently, the execution trace is captured in the form of a structured tree of method calls 
which correspond to the execution of the application. Note that the static part of our approach reduces the number of rules that have to be considered in the dynamic part, therefore it reduces the number of 
tests that cover the policy. The following sections detail the two steps of our approach. 
\subsection{Static Analysis: Identification of Possible Accesses}
\label{sec:static_analysis}
\begin{figure}[t]
\begin{center}
\includegraphics[width=8cm, height=8cm]{Approach.pdf} 
\caption{The Overall Approach}
\label{Approach Description}
\end{center}
\end{figure} 
An access control policy regulates accesses made by system users (subjects) to protected resources (targets). We assume that users of the application and resources are represented in the application class diagram under consideration using classes. In particular,  we consider that the application's class diagram includes classes which represent subjects and classes which represent services offered by the application. In this context, possible accesses are possible interactions between classes representing subjects and those denoting resources.
When subjects and resources are modeled in the form of classes, some accesses are not possible due to the construction of the application. To clarify this idea, we consider a library management system which comprises users such as professors, secretaries, etc. Protected resources in the system are personal accounts, books, etc. This application's model in the form of a class diagram is shown in Figure \ref{implicitSecurityMechanism}. By construction of this application, a class {\it Secretary} cannot directly call {\it borrowBook} since the program does not have any direct reference from the class {\it Secretary} to {\it Books}. In other words, a call of {\it borrowBook} by an instance of the class {\it Secretary} will inevitably fail regardless of whether the specified access policy stipulates that this call is allowed or not. Note that this implies that there are {\it implicit} security rules inherent to the implementation of the application. 
It is important to identify the set of possible operations for the following reasons. First, this allows the reduction of the number of test rules because only {\it possible} accesses need to be tested. All other accesses are impossible by construction of the application and, therefore, they do not present security risks and need not to be tested. Second, it enables an analysis of the access control policy explicitly specified by security officers. For instance, it allows the identification of permissions in the policy which correspond to accesses which cannot be made, or possible accesses which are unregulated by the security policy. These types of checks are important since they may enable the detection of some ill-specified security rules or some unregulated accesses which should be regulated. 


To identify accesses which can be made by users (subjects) to protected resources (targets), we examine the application's class diagram. This class diagram is inferred from the application code and, thus, it shows the different associations and operations of the different classes of the application. To identify possible accesses, we analyze interactions between the classes which represent subjects ($Cl_S$) and the classes which represent targets or resources ($Cl_R$) in the application. In particular, we consider two types of relationships between subject and target classes, namely {\it association} and {\it dependency} relationships. An association describes a discrete connection among objects or instances of the classes. A dependency is a weaker form of relationship which indicates that one class depends on another because one of its method requires the use of the other class. More concretely, when a class $R_1$ is associated with a class $T_1$, typically $R_1$ would have an attribute which is an instance of $T_1$. On the other hand, when a class $R_1$ depends on $T_1$, then $T_1$ appears as parameter variable or a local variable in one of the methods of $R_1$. 
We formalize our analysis of class diagrams using First-Order Logic as a representation language \cite {logics} as follows. 
To represent the different elements of a UML class diagram, we consider the use of predicates {\it class(ClassName)} are used to represent classes of the application 
and {\it sclass(ClassName)} and {\it rclass(ClassName)} to denote classes which represent system subjects and resources respectively. For example, the classes {\it Professor} and {\it Book} are represented as follows. 

\srdl{$class(professor) $\hspace{70pt}$class(book)$}
{$sclass(professor) $\hspace{70pt}$rclass(book)$}

\noindent We represent the {\it public} operations supported by classes and their parameters using {\it class\_operation} and {\it operation\_parameter} respectively. For instance, the following facts specify that the class {\it Book} supports the public operation {\it borrow} which has a parameter of type {\it Professor}.

\srsl{$class\_operation(book,borrow) $\hspace{50pt}$operation\_parameter(book,borrow,profesor)$}

\noindent The associations between classes\footnote{Note that aggregations and compositions are particular types of associations.} are represented using {\it association\_end(Classe1, Name,Classe2)}. For instance, we represent the association between {\it Personnel} and {\it PersonalAccount} as follows.

\srsl{$association\_end(personnel,account,personal\_account) $\hspace{30pt}$association\_end(personal\_account,owner,personnel)$}


\noindent To take into account dependency relationships between classes, we consider that a class $D$ depends on another class $K$ through an operation $Op$ if one of the operations of $D$ has a parameter of type $K$. We specify this as follows.

\srsl{$dependency(S,Op,R)\leftarrow class(S), class(R), class\_operation(S,Op), operation\_parameter(S,Op,R)$}  
  
  
%\noindent This is only one form of dependency which may take other forms such as creation, instantiation, etc. We discuss the formalization of these other forms of dependencies in the following. 

We consider that instances of a subject class $S$ can directly execute public operations of a resource class $R$ if an association exists between the subject and resource classes. 

\srsl{$can\_execute(S,Op,R)\leftarrow sclass(S),rclass(R),association\_end(S,\_,R), class\_operation(R,Op) $}

\noindent The instances of $S$ can also indirectly execute public operations of $R$ if there exists an association {\it path} from the $S$ to $R$. To identify this relation type, we specify the following rules which give the transitive closure of the relation {\it association\_end}.

\srdl{$ind\_association(S,R)\leftarrow association\_end(S,\_,I)$}
{$ind\_association(S,R)\leftarrow association\_end(S,\_,I),ind\_association(I,\_,R) $}

\srsl{$can\_execute(S,Op,R)\leftarrow sclass(S),rclass(R),ind\_association(S,R), class\_operation(R,Op) $}

\noindent We also consider that $S$ can execute the operation $Op$ on $R$ if there exists a dependency between $S$ and $R$ through an operation $Op$ as follows. 

\srdl{$can\_execute(S,Op,R)\leftarrow dependency(S,Op,R)$}
{$can\_execute(S,Op,R)\leftarrow dependency(R,Op,S)$}

\noindent The first rules above consider operations which access resources on the subject's side while the second rule considers operations on the resource's side. Note that there are other forms of dependency, not considered by our analysis, such as instantiation and creation. The formalization of these forms of dependencies is left for future work but their integration in our work is straightforward once they appear clearly in the abstract syntax\footnote{The abstract syntax is the textual representation of the UML class diagram. The graphical representation is called the concrete syntax.} of the UML class diagram inferred from the application code.

We also need to consider the generalization relation. Therefore, we specify that a class {\it P} is a generalization of another class {\it C} using {\it generalization(P,C)}. A class can execute operations of its more general class. This is specified as follows.

\srsl{$can\_execute(C,Op,R)\leftarrow generalization(P,C), can\_execute(P,Op,R)$}

\begin{figure}[t]
\begin{center}
\includegraphics[width=8cm,height=3.5cm]{ClassDiagram.jpg} 
\caption{Application Class Diagram}
\label{implicitSecurityMechanism}
\end{center}
\end{figure} 
Using the techniques described above, we derive the set of possible operations shown in figure \ref{table} below from the class diagram in figure \ref{implicitSecurityMechanism}. Figure \ref{table} shows possible accesses which can be made from within the application-code when the subject classes are {\it Secretary} and {\it Professor} and the target classes are {\it PersonalAccount} and {\it Book}. Note that we consider operations on both the client side and the resource side. For instance, the operations {\it borrowBook} of {\it Professor} and {\it borrow} of {\it Book} correspond to the same operation but on the client side and on the resource side respectively. We consider the identification of both operations since access controls may be enforced either on the client side or on the resource side or on both. 
Currently, we formalize relationships between classes manually. However, we are working on the implementation of a tool which given the description of an application's class diagram in the abstract syntax of UML, analyses the application's model and automatically derives the different accesses which may be made from within the application.
\subsection{Detection of Redundant and Impossible Rules in Policies}
The identification of the set of possible accesses enables us to filter some rules from the security policy specified by security officers or/and detect some ill-specified rules. To clarify this, we assume that accesses by users to protected are regulated, for instance, by an {\it OrBAC} access control policy \cite{orbac}. A permission rule in {\it OrBAC} is specified using a predicate {\it Permission(Name,Role,Activity,View, Context)}. This predicate stipulates that a permission whose identifier is {\it Name} authorizes {\it Role} (denotes a user in the application) to perform {\it Activity} (correspond to a method execution) on {\it View} (represent a protected resource) when the context is {\it Context}. Prohibitions are similarly defined. A security policy is a set of permission and prohibition rules. For instance, consider the following security policy.
{\it \small 
\begin{center}
$Permission(rule_1,secretary,updateAccount,personal\_account,working\_days)$\\
$Permission(rule_2,professor,updateAccount,personal\_account,working\_days)$\\
$Permission(rule_3,professor,borrow,book,working\_days)$\\
$Prohibition(rule_4,secretary,borrow,book,working\_days)$\\
$Permission(rule_5,secretary,read,book,working\_days)$\\

\end{center}
}
\noindent The policy above shows five access control rules. These rules are identified by the rule names {\it rule\_1,rule\_2,rule\_3,rule\_4,rule\_5}. The policy specifies that both {\it secretary} and {\it professor} are allowed to {\it update} {\it account} when the context {\it working\_days} is true. A {\it professor} is allowed to {\it borrow} {\it book} when the context {\it working\_days} is true but a {\it secretary} can not. A secretary may {\it delete} a {\it book} if it is {\it working\_days}. 

Using the possible accesses which we derived from the UML class diargam, we are able to analyze the policy. For instance, we can detect that {\it rule\_4} is redundant since the operation forbidden by this rule can not be executed. We formally specify this condition as follows.

\srsl{$redundant\_rule(Rule\_ID)\leftarrow Prohibition(Rule\_ID,S,Op,R,Ctx), \neg can\_execute(S,Op,R)$}

We may also detect several misspecified policy rules. For instance, the permission {\it rule\_5} grants an access which is impossible due the construction of the application. This is specified as follows.

\srsl{$impossible\_rule(Rule\_ID)\leftarrow Permission(Rule\_ID,S,Op,R,Ctx), \neg can\_execute(S,Op,R)$}

The detection of this latter category of rules is particularly important since it may reveal problems in the explicitly specified policy by security officers. It may also indicate that the application model does not correspond to the structure that the security officers expect from the application. In both cases, the identification of these problems and their resolution is necessary to ensure the proper functioning of the system. These problems may be resolved either by removing the security rule from the policy or by modifying the application to, for instance, enable a {\it secretary} to read books.

%Once possible accesses are identified, we add to the set of rules to be tested every rule in the  specified policy unless this rule specifies an impossible access, i.e. the rule's (role, activity, view) do not correspond to a possible access (subject, operation, target) in the derived table of possible accesses. For instance, the application of the previous rule on the policy presented in this section removes the rule $rule_4$ from the set of rules to be tested since there is not a possible access in table \ref{table} which corresponds to an access ({\it secretary} , {\it borrow}, {\it book}). Note that this rule may also be removed from the security policy since this access can not be made from within the application and, therefore, needs not to be regulated.
\begin{figure}[!h]
\begin{center}
\includegraphics[width=9cm,height=5.3cm]{tablerules} 
%\includegraphics[width=9cm, height=7cm]{process}
\caption{Possible Accesses}
\label{table}
\end{center}
\end{figure}
\subsection{Dynamic Analysis}
\label{sec:dynamic_analysis}
In this section, we show how the identification of the different possible accesses in the application enables us to locate the PEPs in the application code and to make a mapping between every access and the PEP which evaluates it. Consequently, we are able to determine whether the PEP controlling a given access is located on the subject side or on the resource side. We are also able
 to detect whether an access is uncontrolled. This is particularly important since an access that is uncontrolled by a PEP can not be regulated by the policy. We first introduce some concepts related to access control policy testing then we detail our approach.
   \begin{itemize}
\item \textbf{Software Mutation Analysis:} was introduced in \cite{DeMillo} and relies on the introduction of simple
 faults into the program through the use of mutation operators. These operators are applied to the source program once at a time for each applicable piece of the source code to force changes in the program behavior. 
\item \textbf{Access Control Policy Testing}: is the activity of generating and executing test cases from an access control policy. Access control policy testing enables the verification of whether access control mechanisms correctly enforce the specified policy. 
\end{itemize}
In \cite{mutation}, we have presented different mutation operators that have been applied to access control policies. In this paper, we only use two mutation operators, namely PRP (Prohibition to Permission) 
and PPR (Permission to Prohibition). A concrete example of a mutation applied to an access control rule is shown below:
\begin{itemize}
\item $Permission(rule,administrator, manageAccess, personnelAccount, default)$\\
\item $Prohibition(mutated\_rule,administrator, manageAccess, personnelAccount, default)$
\end{itemize} 
\noindent This example presents the mutation of the rule $rule$ into the rule $mutated\_rule$ by applying the operator Permission to Prohibition. 
The context {\it default} represents a context that is always true, i.e. the permission and prohibition are unconditional. 
Figure \ref{Security Test Example} presents the generated access control test case for the rule {\it Prohibition(rule, borrower, return\_book, book, maintenanceDay)}. 
This security test case verifies the correct enforcement of the policy. 

\begin{figure}[!h]
\begin{center}
\includegraphics[width=8.5cm,height=7cm]{testexample} 
\caption{Security Test Case Example}
\label{Security Test Example}
\end{center}
\end{figure} 

\subsection{PEPs Localisation: Mutation Testing Applied on Access Control Policies}
To locate the PEPs in a Java application, we proceed as follows. First, we construct a policy $P$ which includes an unconditional permission for every possible access in the application. The possible accesses are identified using the techniques presented in section \ref{sec:static_analysis}. We specify this as follows.

\srsl{$Permission(S$:$Op$:$R, S, Op, R, default)\leftarrow can\_execute(S,Op,R)$}

\noindent For instance, if we consider the application in Figure \ref{implicitSecurityMechanism}, the policy will include the unconditional permission {\it Permission(professor:borrow:book,professor, borrow,book,default)} since this permission corresponds to one of the application's possible accesses. We use then mutation analysis to generate for a permission in the policy a corresponding prohibition. Test cases are then for both the permission and prohibition rules. These tests are executed and execution traces are generated. The traces produced are then compared: when the PEP correctly enforces the policy, the execution trace of the original policy and the mutated one differs at exactly the location of the PEP in the code. When the two traces are identical, this indicates that either the PEP is incorrectly implemented  or not implemented at all.
  
 We describe our approach more formally as follows: we consider that a Java application that is regulated by an access control policy is a system $S$. This system consists of a set of methods $M$ and is governed by a policy $P=\{R_{i}\}_{i=1..n}$ where every $R_i$ is a permission security rule which corresponds to a possible access and {\it n} is a natural. A mutated policy rule $R^m_{i}$ is the mutated version of the access control rule $R_{i}$ in $P$ after the application of a mutation operator on $R_i$. A test suite is composed of a set of test cases which covers the original rules $R_{i}$ in the policy $P$ and their mutated version $R^m_{i}$. For every test case, we generate an execution trace. An execution trace is a sequence of method calls $<m_1,...,m_l>$ where every $m_i$ is a method of $M$.  We denote by $Tr(R)$ the execution trace of a the test case of a rule $R$. To document the PEP, we consider $Map\subseteq Cl_S\times M\times Cl_R\times M$. A $map(sclass,op,rclass,pep)$ means that the PEP which enforces the execution of the operation $op$ by instances of the class $sclass$ on instances of the class $rclass$ is the method $pep$. Our map is initially empty at the beginning of the dynamic analysis, i.e. $Map=\emptyset$. %comparison is made between the execution traces of every test case associated with a rule $R_i$ and its mutated version $P_m(R_i)$. 
The execution of a test case typically produces a trace which takes one of the following two forms. 
\begin{itemize}
\item When $R$ is a policy rule $R_i$, we get an execution trace of the form $<a_1,...,a_m,M_p,b_1,...b_n>$ where $M_p$ is the PEP enforcing the policy. In this trace, access is allowed and no security exception is triggered since every $R$ in $P$ is an unconditional permission. 

\item When $R$ is a mutated rule $R^m_i$, we get an execution trace $<a_1,...,a_m,M_p,$ $M_{ex},c_1,...c_j>$ where $M_{ex}$ is the method denoting the triggering of a security exception. Note that the traces of a policy rule $Tr(R_i)$ and of its mutated version $Tr(R^m_i)$ generally differ at the exact location of the PEP. Therefore, we document the PEP by adding the access $(sclass,op,rclass)$ which corresponds to the rule $R$ to our PEP-access map, i.e. $MAP = MAP\cup (sclass,op,rclass,M_p)$.
\end{itemize}

It may occur that the two traces produced by the test cases of a policy rule $R_i$ and its mutated version $R^m_i$ are identical. This generally means that either the PEP is wrongly implemented or that there is no PEP to control this access. 
In this case, we add the entry $(sclass,op,rclass,\_)$ to the map to indicate that there is no PEP associated with the access $(sclass,op,rclass)$. Note that these accesses can not be regulated by the access control policy. 

%A Test Case $TC$ which is run considering the original policy $P$ will produce a trace execution 
%$TC$ $\rightsquigarrow$ $P$ that triggers at least one of the security mechanisms $M_{p}$ in the system. Our intuition is that a
 %PEP will be executed normally once used with the original policy $P$, thus the function $M_{p}$ that triggers the rule $R_{i}$ in the system will not handle 
%a security exception. The trace $TC$ $\rightsquigarrow$ $P$ is a sequence of method calls: 
%$<TC,m_{1},..,M_{p},.....,m_{n}>$ where the Test Case $TC$ calls a method $m_{1}$ and the forward exploration triggers $M_{p}$ at a certain time.
%\item A Test Case considering a mutated policy $P_m(R_{i})$ will engender a program execution $TC \rightsquigarrow$ $P_m(R_{i})$ 
%that will lead to a security exception $M_{ex}$ once $M_{p}$ is called. 
%In this case, the trace $TC$ $\rightsquigarrow$ $P_m(R_{i})$ is a sequence of method calls that can be presented like the following: 
%$<TC,m_{1},.,M_{p},M_{ex} .....,m_{m}>$.
%\end{itemize}
%We mutate the policy $P$ rule by rule and we analyze consecutive differences between $TC$ $\rightsquigarrow$ $P$ and $TC$ $\rightsquigarrow$ $P_m(R_{i})$. 


%The following pseudocode sums up our technique.
%\begin{algorithmic}
%\begin{algorithm}[!h]
%\caption{PEPs Localization Algorithm}
%\FORALL{$R_{i} \in P$}
%\STATE{//Mutate each rule $R_{i}$ in the policy}
%\STATE{Get $P_m(R_{i})$}
%\STATE{ //Execute the test case $TC$ that triggers the mutated rule}
%\STATE {Get $TC \rightsquigarrow P_m(R_{i})$}
%\STATE{//Execute the test case $TC$ that triggers the original policy}
%\STATE {Get $TC \rightsquigarrow P$}
%\STATE {//Derive the trace execution difference}
%\STATE{ $diff_{t}(TC \rightsquigarrow P_m(R_{i}),TC \rightsquigarrow P)$}
%\STATE {//Localize $M_{p}$ relevant to $R_{i}$}
%\STATE {$M_{p}\leftarrow R_{i}$}
%\ENDFOR
%\end{algorithm}
%\end{algorithmic}


\subsection{PEPs Localisation: Trace Analysis}
We implement our dynamic approach through the tracking of the execution of test cases using a technique based on 
Aspect-Oriented Programming (AOP) \cite{AOP}. AOP is a programming paradigm that aims at separating cross-cutting concerns to improve modularity. In AOP terminology, well-modularized crosscutting concerns are called aspects. We use AspectJ, 
an implementation of (AOP) \cite{aspectJ}, to implement a logging concern to track and log the execution of test cases. In AspectJ's dynamic join point model, pointcuts are collections of well-defined points in the execution of the
program. These points indicate which methods should be intercepted. Advices are special methods that can be attached to pointcuts.
We define a logging advice that is run when the program executes the test cases. This advice logs all successive routine calls once
 a given trace is executed. The code in Figure \ref{aspect} shows our TracingTests aspect. The TraceTestsMethods() pointcut logs the execution of all Test Cases using the regular 
expressions *Test. After the execution of each Test Case method, the code in the
after advice is executed and logs all method calls after the execution of Test Cases.
 \begin{figure}[!h]
\begin{center}
\includegraphics[width=8.5cm,height=4cm]{aspect}
\caption{Tracing Test Execution Aspect }
\label{aspect} 
\end{center}
\end{figure}




